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Abstract — Many reconfigurable platforms require that ap- 
plications be written specifically to take advantage of the 
reconfigurable hardware. In a PC-based environment, this 
presents an undesirable constraint in that the many already 
available applications cannot leverage on such hardware. 
Greatest benefit can only be derived from reconfigurable 
devices if even native OS applications can transparently uti- 
lize reconfigurable devices as they would normal full-fledged 
hardware devices. This paper presents how Proteus Virtual 
Devices are used to expose reconfigurable hardware in a 
transparent manner for use by typical native OS applica- 
tions. 

Keywords — reconfigurable computing, virtual device, na- 
tive applications 



I. Introduction 

Software Defined Radio (SDR) £Q refers to the concept 
of implementing various broadcast / telecommunications 
standards in software, and running them on the same gen- 
1 eral purpose hardware. The hardware may be general pur- 
pose processors such as the Intel Pentium series, or may be 
reconfigurable hardware processors such as the Xilinx Vir- 
tex series Field Programmable Gate Arrays (FPGA). The 
promise of SDR has been that devices will become easily 
adaptable and upgradeable, since only a Software Module 
download is needed for the device to support a different 
broadcast / telecommunications standard. 

Project Proteus was initiated by the DSP Technology 
Centre of NgeeAnn Polytechnic (Singapore) to develop a 
low-cost PC-based reconfigurable computing platform, one 
application of which is SDR. 

A common limitation of many reconfigurable platforms 
is that only applications which are fully aware of the exis- 
tence of this reconfigurable hardware are able to take full 
advantage of it. For example, an application would nor- 
mally have to be written to specifically utilize the Appli- 
cation Programming Interface (API) exposed by the Pro- 
teus Software Platform (PSP) |3| to control, reconfigure, or 
exchange data with the reconfigurable device. This repre- 
sents a major barrier to being able to realize the full benefit 
offered by a PC-based reconfigurable computing platform. 

Greatest benefit can only be derived if even typical na- 
tive applications written for the Operating System (OS), 
and not aware of the underlying PSP, can still utilize this 
functionality. For example, the Internet Explorer program 
running on Windows XP should be able to connect to the 
Internet transparently, using the Proteus Platform with a 
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Modem Software Module downloaded. It can only do so 
if the OS is able to view the Modem Software Module de- 
ployed by the PSP as a full-fledged hardware modem de- 
vice. 

This paper introduces the use of 'Proteus Virtual De- 
vices' to virtualize the existence of hardware, correspond- 
ing to the downloaded Software Module on the PSP, to 
the underlying OS. This allows typical OS applications to 
transparently utilize the reconfigurable platform as though 
a corresponding full-fledged hardware device actually ex- 
ists. 

SectionllTlintroduces the architecture of the PSP, Section 
lllll describes how a 'Proteus Virtual Device' exposes recon- 
figurable hardware functionality to native OS applications, 
Section Hvl illustrates its use with a Virtual Modem Device 
and the Windows Hyperterminal application, and finally 
Section Ivl concludes the paper. 

II. Proteus Software Platform Architecture 

The Proteus Software Platform (PSP) has been divided 
into four main component blocks: the PSP Core, which 
holds the common set of interfaces and functionality, and 
three other components: the Proteus Application, Hard- 
ware Abstraction Modules (HAMs), and Software Modules. 
This segmentation is illustrated in Figure ^ 
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Fig. 1 

Components of the Proteus Software Platform 



A Hardware Abstraction Module (HAM) serves as the 
layer of abstraction between the PSP core and the under- 
lying hardware. Any hardware device can therefore be uti- 
lized by the PSP through a HAM. 

A Software Module is a package of one or more algo- 
rithms that are deployed to the reconfigurable hardware 
by the PSP, as and when desired by the end-user. The 
Software Module may be a simple algorithm such as a Fast 
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Fourier Transform, or a full telecommunications standard 
such as GSM or Bluetooth. 

When a Software Module has been selected by the user 
for deployment, the PSP will resolve the type of hardware 
available (such as FPGAs) via the HAM, and match them 
with compatible algorithm implementations from the Soft- 
ware Module. 

The Proteus Application represents the high-level PC 
application that has been written to utilize the PSP API to 
control the platform operation, and to present a graphical 
user interface to the end-user. 

However, we wish to avoid this need for a user to interact 
with the reconfigurable platform via the user-interface of 
the Proteus Application. The next section describes how 
this transparency of use is introduced via the Proteus Vir- 
tual Devices. 

III. Proteus Virtual Device Architecture 

An Operating System abstracts underlying hardware 
from native user applications. These applications indirectly 
utilize hardware via the API exposed by the OS. At the 
hardware end, a device driver has to be written to allow 
the OS to control and exchange data with the hardware. 
This set of layers and interfaces is illustrated in Figure |5J 
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Fig. 2 

Data exchange layers between User Application and 
Hardware 



As an example, when an email client application wishes 
to connect to the Internet, it signals this requirement to 
the OS. The OS then identifies a suitable hardware device 
that can establish an Internet connection, and utilizes the 
corresponding device driver to perform this task. 

Therefore, to allow native OS applications transpar- 
ent use of reconfigurable hardware as full-fledged ordinary 
hardware devices, a redirection has to be introduced at the 
'device driver' layer. This redirection will pass all calls 
from various device drivers to the same general purpose 
reconfigurable hardware. Effectively, these device drivers 
will represent 'virtual' devices because no specific hardware 
exists for that driver alone - all the 'virtual device' drivers 
redirect their calls to a common reconfigurable hardware 
device, which dynamically reconfigures itself according to 
the requesting driver. This concept is illustrated in Figure 

El 

To arbitrate between multiple requests for use of the 
reconfigurable hardware, and to control download of the 
Software Module corresponding to the driver invoked by 
the OS, all interfacing between the reconfigurable hard- 
ware and the virtual device driver is done over the PSP, as 
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Fig. 3 

Data exchange layers between User Applications and 
Reconfigurable Hardware 



shown in Figure The virtual device represented by the 
OS-specific driver is therefore termed a 'Proteus Virtual 
Device'. 
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Fig. 4 

Data exchange layers with Reconfigurable Hardware via 
the PSP 



A Proteus Virtual Device therefore appears to the OS to 
be a full-fledged hardware device, when in fact it redirects 
all communications to the Software Module downloaded to 
the PSP. For example, Figure shows the Device Man- 
ager of Windows XP with a Proteus Virtual Modem De- 
vice driver installed; this appears to the OS as a full-fledged 
hardware modem device, when internally it actually links 
up with the Modem Software Module downloaded to the 
PSP. A simplified illustration of this is shown in Figure H3 

Each Proteus Virtual Device is distributed as a HAM, 
which includes the OS-specific driver and an OS-specific 
native library. The PSP accesses the Proteus Virtual De- 
vice driver via the native library. 

Since Proteus Virtual Device drivers act as interfaces 
over which data is exchanged between the OS application 
and the PSP, there is a need to open two 'handles' to the 
virtual device, one for the OS application and the other for 
the PSP. 

Each Microsoft Windows Driver Model (WDM) 4 driver 
will have a 'device object' structure created for it by the 
OS, to represent the device for which a handle has been 
opened. A handle can be retained by a single application 
only, so after a handle has been opened by the native user 
application, a second 'shadow device object' has to be cre- 
ated for the handle passed to the PSP. The device object 
associated with the first handle opened by the native user 
application is called the 'actual device object'. 

When a read or write operation is performed on a handle, 
the data is exchanged through ringbuffers shared by both 
handles / device objects. This is possible because a Win- 
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Fig. 5 

Virtual Modem Device in Windows XP 
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Fig. 7 

Data exchange between an OS application and the PSP, over 
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Fig. 6 

Modem Software Module 



dows driver is shared among all device objects created - the 
same read / write handlers are called, but in the context of 
the device object corresponding to the handle used. The 
shadow device object exists for the sole purpose of allowing 
another handle to be opened - all other fields of the device 
extension (other than the pointers to the ringbuffers) are 
not used. Using the Virtual Modem Device as an example, 
Figure illustrates this set-up of device objects and the 
data exchange between the native user application and the 
PSP, via the handles opened to each device object. 

IV. Using the Proteus Virtual Modem Device 
with Microsoft Windows Hyperterminal 

To demonstrate the operation of a Proteus Virtual De- 
vice, a Virtual Modem Device HAM has been developed. 
The Microsoft Windows Hyperterminal application can be 
used to transparently establish a connection using the Pro- 
teus Virtual Modem Device. 

The PSP is firstly started to deploy a Modem Software 
Module. This causes the Virtual Modem Device HAM na- 
tive library to open a handle to the Proteus Virtual Modem 



Device, and the OS to create the 'shadow device object'. 
Once this is done, Hyperterminal can be started. 

Since the OS views the Proteus Virtual Modem Device as 
a full-fledged hardware device, the 'Proteus Virtual Modem 
Device' can be selected as the device to be used in the 
Hyperterminal 'Connect To' dialog, as shown in Figure |H1 
Entering any number to dial and clicking 'OK' will start 
the connection process. This causes the second handle to 
the device to be opened by Hyperterminal, and the OS to 
create the 'actual device object'. 

Data exchanged with the PSP can be observed in the java 
debug output window, as shown in Figure |5J The simple 
AT parser provided with the Modem Software Module will 
return the 'CONNECT' string when it receives the 'ATD' 
command from Hyperterminal during this connect process. 

V. Conclusion 

This paper has described a technique of using Proteus 
Virtual Devices to expose reconfigurable hardware in a 
transparent manner for use by typical native OS applica- 
tions. This feature allows PC-based reconfigurable plat- 
forms to be fully leveraged on by the many existing OS 
applications that were developed to utilize only full-fledged 
hardware devices. 
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Fig. 8 

Hyperterminal Connect-To dialog 
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Fig. 9 

PSP DEBUG OUTPUT DURING CONNECTION ESTABLISHMENT 



Acknowledgments 

Special thanks to the Proteus Team, especially to Philip 
Wong, Kelvin Lim, Kelly Choo, and Andreas Weisensee. 
Thanks also to Chua Beng Koon and Lim Choo Min of 
NgeeAnn Polytechnic's Electronic and Computer Engi- 
neering Division, for their support of this project. This 
work was funded by the NgeeAnn Kongsi (Singapore) and 
NgeeAnn Polytechnic's Innovation & Enterprise Office. 

References 

[1] J. Mitola, The Software Radio Architecture, IEEE Communica- 
tions Magazine, vol.33, no. 5, pp. 26-38, May 1995 

[2] Project Proteus, DSP Technology Centre, NgeeAnn Polytechnic, 
Singapore, http://www.projectproteus. org 

[3] Darran Nathan, Kelvin Lim Mun Kit, Kelly Choo Hon Min, 
Philip Wong Jit Chin, Andreas Weisensee, A High-Level Recon- 
figurable Computing Platform Software Frameworks, arXiv.org, 
|cs.AR/0 405015 May 2004 

[4] Walter Uney, Programming the Microsoft Windows Driver 
Model, Microsoft Press, 1999. 



